The online racing simulator
Searching in All forums
(583 results)
Invisible LOD2 - no need for it (or excessive LOD2)
Scawen
Developer
One of the checks recently added to our upload system detects if there is a LOD2 with no polygons in it, and the upload is rejected in that case. This is surprisingly common in submitted mods, although there is no point in this type of configuration.

If you want to submit a mod before you have created a proper LOD2 (for middle distance and shadow) then you should put the physics LOD (which is LOD3 in a properly finished mod) into LOD2.

That is OK for unfinished mods, and you will at least have a shadow and not drive around with a vehicle that is invisible in the middle distance.

FINISHED MOD: (GOOD)
LOD1: Many triangles
LOD2: Medium triangles (e.g. around 1000, see official cars)
LOD3: Physics

UNFINISHED MOD: {OK)
LOD1: Many triangles
LOD2: Physics

WRONG:
LOD1: Many triangles
LOD2: [empty]
LOD3: Physics

EDIT: ALSO WRONG:
LOD1: Many triangles
LOD2: Many triangles, holes, ugly mess
LOD3: Physics
Last edited by Scawen, .
Scawen
Developer
Well you can discuss amongst yourselves, but I am only one programmer and I think the priority is completing the new graphics and physics version. Limits were discussed and set long ago. Unfortunately, hackers learned to get around the limits. I've spent the last two years working on improvements for mods, delaying the big release that everyone wants. I worked right up to the limit of my health before the Christmas holidays, to allow me to get back to the main task.

Now I have learned half the mod creators use a hack to bypass the limits, while other people complain about glitches when people leave the pits. My job is to make sure that doesn't happen, then get back to what I am supposed to be working on. The game is supposed to run smoothly and that is the most important thing.

I'm not going to drop what I am working on to continue working on more updates for mods. I hope you understand.
Release this weekend - call for testing
Scawen
Developer
Dear Racers,

We plan to release a new official version this weekend, probably on Sunday.

There's a lot in it, including many improvements for mods. In the new year I will be focussing on the new graphics and physics version, but that is not what this patch is about.

Please test the LFS version now if you can.
LFS Test Patch: https://www.lfs.net/forum/thread/106005

If you are a mod creator, please test the new editor patch.
LFS Editor Test Patch: https://www.lfs.net/forum/thread/106004

You'll see the list of changes is really long. Have a look through the changes if you can!

Or just get the patch and do what you normally do, let us know if there are any problems.

Thanks! Thumbs up
Spinoff : Moving subobjects
Scawen
Developer
A lot of people would like to use the popup headlights for other purposes. As the patch release is next weekend, I don't have time to do everything that could be done.

But I wondered if it might be possible at least to enable existing light switches to operate moving parts.
E.g. you could use /light rfog/ffog/extra to operate an item if it was set to be connected to that switch.

Keeping it simple at first, that might be, instead of an object type "popup headlight" you would set "rotating object" as the object type then link it to headlights/rfog/ffog/extra.

Now, in my opinion that would already do a lot of what people want, without me having to add extra text commands, user inputs and data sent over multiplayer (in two separate versions of LFS). It's kept simple by using existing switches. So I hope this may be possible in the time available.


But I also wanted to think on a bit further, although this starts to sound too complicated for this week when I already feel under a lot of pressure. The release next weekend is important to me after a very hard work year and I want a fresh start to finish the other version next year, so we can release the new physics, graphics and updated tracks.

Anyway, I couldn't help thinking a bit as I rolled around in bed and had to get up early again and write some things down.

I came up with this.

Types of object:
- rotator [like current headlights, rotates a given amount]
- slider [moves along an axis a given distance]
- spinner [rotates at a given speed]

Rotator and Slider can connect to:
- boolean switches (e.g. light switches)
- axis (e.g. throttle, brake, clutch, steer)

Spinner can connect to:
- boolean switches (e.g. light switches - spins at given speed)
- moving parts (e.g. engine, drive shaft - spins with object or multiple of it)

Well, that's the concept.

Questions remain:

Amounts:

Range of values for "Rotator" amount?
Currently goes from -180 to 180 degrees. Considered enough for popup headlights and probably for most purposes.

Range of values for "Slider" amount?
Given storage limitations, a range of -1000 to 1000 is available. If the resolution is 1mm that would allow movement of 1m. Probably good for many things, but maybe we need an alternative "Large slider" that has resolution of 1cm (allowing movement of up to 10m)

Range of values for "Spinner" amount?
1) When connected to a boolean switch, this would be a set rotation speed (rpm) when connected to a boolean switch. Again, the base value is from -1000 to 1000. Would that be OK if it plainly represented RPM? So you could have a spinning object 1rpm, 2rpm, 3rpm... up to 1000rpm.
2) When connected to a rotating component, it could be a multiple. Usually 1 (e.g. rotate with driveshaft). But maybe 0.5 (e.g. camshafts rotate at half engine speed). Or maybe some things rotate faster than the rotating component? So what sort of range, given again we have -1000 to 1000 but clearly this must be scaled down massively (nothing will rotate at 1000 times the rate of an component it is connected to). Maybe 10 times the speed would do, so it could go from 0.01 up to 10 times the speed of the connected part?

Rotating parts that Spinners could be attached to:

Engine
Drive shaft
Final drive (diff)
Rear (left or right) wheel
Front (left or right) wheel
Steering wheel angle
Steer angle (left or right)

Input axes that Rotator and Sliders could be attached to:

Steering wheel (-1 to 1)
Throttle (0 to 1)
Brake
Clutch
Handbrake
Last edited by Scawen, .
Scawen
Developer
Quote from neozixxs :xrr should be like that ? Great update btw Big grin i really like the new features

Oops, I forgot to set the layer correctly so it only appears in the road cars. Looking


Quote from ScammerGamerLOL :Will there be graphics and night mode in the 0.7E? and how many days left until release?

No, 0.7E has absolutely nothing to do with the new physics and graphics.

0.7E is planned to be released next weekend. It would be really strange to release something we'd been working on for 10 years without even testing it. I've said it a lot of times now. 0.7E allows me to stop working on mods for a while, so finally I can work on finishing the physics and graphics for the really big release.
Scawen
Developer
As said before, it's pretty easy to think of 1000 things that you could say "why on EARTH is THIS feature not done". And let's suppose each of those things take 1 day or a week or a month to do. Assume on average each would take a week. And let's suppose there are 50 weeks a year.

Now we are talking 1000/50 so then in 20 years I could get those things done. And I suppose some people would say... YES! do all those obvious 1000 things, before releasing the new tyre physics and graphics system that has already been coded and that we are waiting for.

But, here's the problem, I do not agree with that. My plan is to release this really big update, 0.7E, with huge amount of mods support, that I have worked nearly every day for a couple of years on, long days, weekends and holidays. And then get back to the new physics and graphics update that I mentioned already. If you don't like that plan, that is your problem really, not mine. As also mentioned, there are other programmers who can write the feature you requested. I've already provided a solution that allows that to be coded. It's called "InSim".

There's only one programmer on the core game, so guess what... I don't have time to write every single peripheral that you could wish for. I did however provide an interface so you can make your own, so why don't you get cracking and sort it out yourself?
Scawen
Developer
Quote from Rizzerz :Hello, quick question, now the slots to join on server its like 78, when will you increase the slots to drive to 70?

The plan is to look at increasing max cars in race sometime after the big update is released.

We need to see how the new physics works on everyone's computers (in the multithreaded system, which should help, if CPU has at least two, but preferably four cores) and after evaluating that we can see how the performance will be when extending to 48 cars in race.

The purpose of this current test patch is to release an official version with much better mod support than in the currently official version, so that mod makers can keep making nice mods while I get on and finish the physics for the new version (improved tyre physics and much better graphics, with significantly updated tracks) that we are all waiting for.
Scawen
Developer
Quote from BorislavB :Nice update on lights, you can update and icons also and same on dashboard on cars.

All these icons are now available on the dashboard, except the sidelights one. But you have to wait for the mod maker to implement them.

Quote from Gabey1 :Would be nice if we could have a key bindable to toggle high beam (in controls). Like in real cars.

That's there.
/light head dip_full

Quote from Gabey1 :EDIT: To be fair, i'd like to hear what's stopping you from incorporating bindable toggles for all the lights (fogs,extra,low(already there),hi beam etc) in the game controls.

There are many thousands of things I could do or could have done. For every single one of them you could ask why on earth have I not done them already. Well, each one takes a day, half a day or a week or a month.

Please try to give me a break with the requests. As I keep pointing out, every single thing I do in this public version has to be done twice. The whole idea of this patch is to provide important updates to the mods system, so that I can STOP working on this public version, and get the tyre physics finished so I can release the new graphics version next year.

If, instead, I worked on 1000 totally obvious things that should have been done years ago, and each took a day, then 3 years later I can start to finish the graphics system. I hope you see what I mean.
Test Patch D64
Scawen
Developer
WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST

PLEASE... NO OFF TOPIC FEATURE REQUESTS!


Hello Racers,

Here is a new test patch: 0.7D64

Please read the list of changes below.

0.7D64 is SEMI-COMPATIBLE with 0.7D

- You CAN connect online with 0.7D
- You CAN play single player replays from 0.7D
- Some rare mods or bike mod setups can cause OOS
- You can use mods from the latest LFS Editor (allows new features)

Please back up or rename your LFS.exe from version D so you can revert to it if necessary.

Known OOS cases when joining a server earlier than D50:

Loading more than 2400 objects in a layout
Use of a bike setup with adjusted fork ride height
Use of a car with visible spare + different size wheels


Changes in D64:

Graphics:

FIX: Subobject transparency was not visible in forces view


Changes in D63:

Graphics:

Spinner objects now stop nicely at the default position
Support for the new light switch options in Editor D63

Misc:

LFS now always checks for existence of some folders at startup


Changes in D62:

Korean IME:

FIX: The fix in D61 was incomplete and should work now


Changes in D61:

Graphics:

Vehicles are no longer fully regenerated on every mirror adjustment
- fixes bug that moved subobjects were reanimated on mirror adjust

Korean IME:

FIX: Since 0.7C the last character would be lost on pressing enter

Interface:

FIX: Handicaps message after /h_mass now states correct added mass


Changes in D60:

Graphics:

Support for stretched tyres (when rim is wider than ideal)

Commands:

/key command accepts 12 keys described by a word (see Commands.txt)

Misc:

Updated document Commands.txt (in docs folder)


Changes in D59:

Graphics:

Small indicators on side of XRG/XRT/FXO/LX4/LX6/RAC/FZ5 now flash
Subobject indicators left / right now relative to whole vehicle
FIX: Lighting of subobjects and wheels was as if at vehicle centre


Changes in D58:

Lights:

Headlight switch now incompatible between versions < D50 and >= D50
FIX: Extra light of remote cars was not visible when switched on

Moving subobjects:

Popup headlight system generalised for moving objects with switches
Light / horn switches work even if car does not have that feature


Changes in D57:

FIX: Transparency could vanish with more than one vehicle in view
IS_PLH now allows 'silent' update (with Flags bit 7 (0x80) set)


Changes in D56:

Transparency now works correctly with popup headlight objects
Popup headlights now support flip function


Changes in D55:

Multiplayer:

FIX: LFS could crash if a player left when a mod was not downloaded

Graphics:

Popup headlights and internal mirrors are excluded from forces view
Skin mappings that move with driver side swaps no longer avoid flip


Changes in D54:

Lights:

FIX: XR GTR mistakenly had the road car popup lights enabled

Interface:

Pedals are now shown to the left of the list of connections

AI:

FIX: AI would reverse assuming "stuck" during stop-go penalty


Changes in D53:

Lights:

Lights now work on subobjects (e.g. bike handlebars)
Popup headlights are also supported (already on XRG and XRT)


Changes in D52:

Lights:

Support for multiple light mappings (enabled in LFS editor D52)
Virtual gauges now show sidelights / low beam / high beam symbol

Dashboards:

Support for new options (minor updates) now available in editor

Wheels:

Support for new rim material settings (enabled in LFS editor D52)
Wheels set to "inside covered" now match the editor
- "inside covered" or "open wheel" only affect logo and lighting
- visibility of brake disc and spoke object is no longer affected


Changes from D48 to D51:

Interface:

New icon for LFS.exe includes 256x256 icon image
Commands /status F11 and /status F12 are now available during SPR
F key /commands are processed immediately (not added to text dialog)
Connections list in game / race setup screen can have a scroll bar
- scroll with mouse or Page Up / Page Down keys
New +/- buttons to adjust size of text in connections list
FIX: Various text commands such as /spec now disabled in replays

Lights:

Side lights, low and high beam headlights are now supported
Text command /light (requires two parameters) to switch lights:
/light ind [off/left/right/all] - switch indicators/hazard lights
/light head [off/side/low/high/low_off/low_high/next/prev] - lights
/light [rfog/ffog/extra] [off/on/toggle] - switch fog/extra lights
/light all [off/on] - switch all switchable lights off/on at once
Key '3' now toggles between off & low beam like /light head low_off
SHIFT+3 goes through all headlight states like /light head next

Multiplayer:

Maximum possible connections increased to 79
- there will be a higher charge for 79 connections
- free hosts are still limited to 47 connections
- maximum cars in race has not been increased

InSim:

License byte added to IS_NCI packet (after Language byte)
IS_PLH packet sets handicaps for individual players
TINY_PLH - request IS_PLH listing player handicaps
SMALL_LCL - full control of lights including fog and extra lights

Commands:

/h_mass username X - set added mass for user's car
/h_tres username X - set restriction for user's car
/teamarrows=no/yes - arrows on non-race small map use name colour

Layouts:

Max objects increased to 3000
NOTE! using more than 2400 objects will cause OOS on servers < D50

Bikes:

Increased maximum value for brakes, suspension stiffness, damping
NOTE! higher values not available when connected to servers < D50
FIX: Fork tubes misaligned if ride height adjusted in other setups
NOTE! adjusting fork ride height will cause OOS on servers < D50
FIX: Weight distribution was wrong if any trail reduction was set
FIX: Wheel masses not correctly positioned for trail reduction

Engine:

V16 engine is now available and some classes allow larger engines
New firing order for I5, V6, flat-8 and V10 engines (affects sound)
FIX: V12 engine firing order was wrong causing poor sound quality

Incompatible updates:

New features for mods including wheel and passenger positions
Support for new rim styles and different wheels front and rear
Fog lights are now functional if enabled by the mod creator

Graphics:

Removed wheel LOD reduction that was related to angle of view
Tyre manufacturer now appears at the top of tyre after reset

Dashboard:

Support for new dashboard lights / symbols: sidelights and neutral

Translations:

Updated translations - thank you translators


Changes from D to D48:

Interface:

A small map is now displayed at Layout Square if there is a layout
New display in F9 / F10 views shows estimated laps given fuel use
Engine health (with colour code) is displayed in F9 / F10 views
F9 / F10 extra displays are now switchable (Options - Display)
Speedo and tacho are moved UP if required for extra displays
CT display now uses dot matrix font if translation allows it
Driver / fuel buttons in garage are now only shown if relevant
Speed at redline is displayed beside each gear ratio in setup
Simple versions of F11/F12 displays are now available during an SPR
A message shows the name of any mod that can't be loaded in an SPR
Four-character mod names are shown in results table instead of MOD
Downforce tab is now shown for all vehicles
- previously was only for those with adjustable wings
- shows an estimated maximum speed based on wind resistance
- note: the estimate does not consider rolling resistance
FIX: Crash when two events on calendar used same event image
FIX: Calendar time could be wrong near start of daylight saving
FIX: Small camera movement on releasing LMB after 2-button rotation
FIX: Chat text in mods screen is now in front of interface buttons
FIX: User names that start with '.' now correctly displayed in chat
FIX: Crash if /track command was used while generating AI path info
FIX: AI skill level always used Latin codepage in F11/F12 menus
FIX: Engine brake reduction had no effect for EV but was visible
FIX: /setlap command error if name coloured and number 4 chars long
FIX: Replays auto-named with special characters could appear wrong

Controls:

A force feedback display is shown below the pedals (bottom right)
FIX: Mouse wheel gearshifts are now equivalent to 100ms keypress

Game:

Possible to reset if an approaching vehicle is moving slowly enough
Reset is now possible during a pit stop if the state is "finished"
Speed limiter (at 80 km/h) can be manually enabled if no pit lane
Auto gear shift: downshifts are now done at slightly lower rpm
FIX: Auto shift *up* did not work if max power rpm above redline
FIX: Driver swap enabled very high speed limiter if no pit lane

Mods:

An EV charge/discharge power bar in place of the clutch bar
- only visible if Options - View - Show pedals is enabled

A new "Cleanup" mode in the mods screen
- you can select to keep latest mods and test mods
- there is not yet a feature to keep replay mods

Support for new options set per vehicle instead of by race class
Support for "hub" subobject that moves and rotates with a wheel
Support for new pit speed limiter flashing light option
One wheel drive and no anti-roll if wheels are staggered
Click Skin ID in garage colours tab to copy ID to clipboard
Hold CTRL in Garage: Mods button becomes Test (direct to Test mode)
Opening mods screen is prevented if a rating request is in progress
FIX: Mod with 27 character name appeared in mods screen Test mode
FIX: Crash if mod had more than 64 materials

Dashboards:

Engine damage light on dashboard is now available if set in editor
Support for new speedo and tacho style options (see editor notes)
Support for dashboard backing texture system, text colours, opacity
Can also set background colour without supplying a backing texture
New needle pivot texture works better on light coloured dashboards
Dashboard brightness should now be the same as in the editor
- this update also affects the RB4 and MRT5 (recently updated)
FIX: Text size on dashboard more closely matches text in editor
FIX: Brightness of multi function display now matches the editor

New steering model for bikes:

Improved handling and braking ability
- Feet down steering model up to 7 km/h
- Low speed model only from 7 km/h to 18 km/h
- Interpolated model from 18 km/h to 36 km/h
- High speed model only above 36 km/h
FIX: Steering glitch between feet down model and low speed model

AI vehicle control:

Improved braking prediction so less running wide at corners
- considers brake balance (which is not ideal for every corner)
- can result in better lap times due to improved line following
AI braking prediction now takes account of engine braking
AI can now ride motorbikes (a bit slowly due to safety margin)
AI will drive more gently when off track on a bad surface
Bikes slow to avoid taking off over large humps in the road
Avoid unnecessary downshifts by looking ahead to see if needed
FIX: Sometimes could reach a maximum speed and stop accelerating

AI misc:

Distance to vehicle considered dangerous now depends on length
Distance to vehicle considered safe is reduced at low speed
- should prevent long vehicles hitting the brakes on green light
- gaps between vehicles may be smaller when speed is below 20 m/s
AI can enter configs with no path (but will not drive)
AI can now enter the game with an object (to just sit there)
Better collision avoidance when close behind or beside others
Reset is available even after engine switched off after long wait
Message history is no longer enabled for AI path generation
FIX: AI can now reset if in contact with a stationary vehicle
FIX: Errors in fuel calculation related to "Refuelling allowed"
FIX: It was possible for the fuel calculation to report 0 stints
FIX: A hang generating path for a mod with "Max up" wrongly set

AI in pit lane:

Target speed 1 km/h slower in pit lane to avoid speeding by mistake
- was possible for a powerful car to overspeed shifting 1st to 2nd
Improved driving in pit lane when close behind other drivers
Avoid excessive downshifting when approaching speed limit zone
Approx 1 second safety margin entering pit lane to avoid speeding
Use speed limiter or throttle to avoid wheelspins causing speeding
Smoother transitions switching between main path and pit lane path
FIX: Choice of pit stop box was wrong (bug introduced in 0.7B)
FIX: Slow start / stuck in pit stop if max torque at very low rpm
FIX: Some mods would brake too gently and miss the pit stop point
FIX: Some mods would overshoot their pit garage when parking
FIX: Can now reset at the end of a pit stop (e.g. fallen bike)

AI overtaking:

Various improvements to improve the overtaking decisions
Overtakes are considered on a group instead of individuals
Better estimate of the possibility and duration of a pass
Pass decision from low speed now allows for acceleration
When planning a pass time is allowed to pull in after pass
More distant consideration of other vehicles at high speed
There should be fewer dangerous overtakes in braking zones
FIX: AI could get pointlessly stuck behind a slower vehicle

Regional downloading system:

We now have 3 download locations for mods (NL/JP/US)
Faster downloads if you are in N/S America or Asia/Oceania
Locations in Asia and Oceania will download mods from Japan
Locations in North and South America will download from USA
Download redirection is handled automatically by our server
Regional downloads can be disabled by a new Misc Option
Yellow redirect message is shown the first time you are redirected

Graphics:

Dust colour on grass and dirt tracks now uses a dirt colour
- previously used average colour of surface which looked odd
- smoke and dust acquire lighting colour from car's location
FIX: Mudguard / handlebar / trailing arm subobject could disappear

Physics:

Improved bike physics (affects lean angle and tyre forces)
Pit speed limiter now based on drive speed instead of world speed
- prevents wheelspins (e.g. at RO) pushing car over the speed limit
FIX: Narrow cars were sucked in when near fence or narrow barrier

Audio:

Tone variation limited to 0.99 to prevent an engine sound bug
Switched off experimental "Prevent clipping" option by default

Multiplayer:

Improved setting of tyre state after receiving a position packet
- previous location of tyre contact is better estimated (for forces)
- most noticeable when viewed car had not been on screen for a while
- e.g. after tabbing to another car or fast forwarding a replay

Misc option "Full physics for remote cars" is enabled by default
- low res physics previously used for cars other than the 4 nearest
- option approximately doubles CPU usage by physics in multiplayer
- could cause issues at turn 1 with many cars depending on PC power
- use profiler display to check CPU usage with the option enabled
- see profiler by pressing car icon then P in Misc/Graphics options

Engine damage repair in pit stop
- yellow counts as minor damage (6 seconds)
- red counts as major damage (12 seconds)

Team arrow colours on small map are now enabled by a host option
- arrows on non-race small map take colour of first name character
- option is not yet available but is coded as /teamarrows=no/yes

Cancel button and ESC key to cancel the process of joining a host
- the currently downloading skin or mod is allowed to finish first
Temporary (free) hosts are shown without colours in List of Hosts
Stationary cars can now lag for longer (3 seconds) before vanishing
FIX: Remote car using pit speed limiter did not move smoothly
FIX: Crash enabling filter in List of Hosts after all were disabled

InSim:

IS_CPP packet with Time = 0 is instantly processed (not stored)
- allows it to be followed immediately by an IS_CPP with Time > 0
FIX: ZByte was not set in IS_OBH packet

New commands:

/status none|F9|F10|F11|F12|next|prev - sets status screen
E.g. /status next will cycle through the F9 to F12 status screens
(you could assign it to a CTRL+ or ALT+ key and then a wheel button)

/liveset and /pitins - do the functions of F11 and F12 menus

You can use operators:
= (set value)
+= (add to value)
-= (subtract from value)

Examples:
/pitins ftyre = r3 : change front tyres to R3 in pit stop
/pitins rtyre = super : change rear tyres to road super
/pitins fpressure = 1.1 : set front tyre pressure to 1.1 bar
/pitins fpressure += 0.1 : increase requested pressure by 0.1 bar
/pitins cancel : cancel all pit instructions
/pitins tyres always : change all tyres
/pitins tyres 20 : change tyres if wear > 20%
/liveset bbal 60 : set brake balance to 60%
/liveset rarb -= 0.1 : decrease rear ant-roll bar by 0.1

Available options for /pitins:
fuel, tyres, repair, symmetric
ftyre, fcamber_l, fpressure_l, fcamber_r, fpressure_r, fwing
rtyre, rcamber_l, rpressure_l, rcamber_r, rpressure_r, rwing
cancel, fcamber, fpressure, rcamber, rpressure

/pitins pressure commands can accept unit (psi/bar) (no unit = bar)
E.g. /pitins fpressure 30 psi

Available options for /liveset:
bbal, farb, rarb

Multiple commands on single line:

Multiple commands can now be added on a single line which sometimes
can avoid the need for a script file, e.g. to set a button to
change tyres in pit stop, you could use a double command:
/pitins ftyre super /pitins rtyre super

NOTE: some commands cannot be followed by another command:
/say /echo /join /rcm /pass /msg /altf /ctrlf

Maximum length of command and F key text increased to 95 characters
Wider text display in CTRL+ and ALT+ tabs in controls screen


INSTALLATION:

A FULL version of LFS 0.7D must already be installed


To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7D25


DOWNLOAD:

IF YOU ALREADY HAVE 0.7D:
PATCH 0.7D TO 0.7D64 (SELF EXTRACTING ARCHIVE)
https://www.lfs.net/file_lfs.p ... =LFS_PATCH_7D_TO_7D64.exe (1.8 MB)
Last edited by Scawen, .
Scawen
Developer
We are getting near the next test patch, which will be semi-compatible (same physics and graphics, new mod options).

I've updated the change log in the first post, to bring all the updates from D to D48 into the same list.

I hope it makes sense. I feel a bit like this: Ya right

D to D48: https://www.lfs.net/forum/thread/102117
Scawen
Developer
The AI have had many improvements that mean they can get around in most vehicles on most tracks. They have an adaption system that deals with brake balance etc. (you may read the thread, it's long).

Previously they were very optimised for the LFS vehicles and not adaptable enough for mods. So it's possible that for some LFS vehicles, they are now slower, because of the small safety margins they must leave in order to not crash so many mods as they did before.

But...

1) Your thought of "scam bots" is totally against my philosophy of game production. I have no interest in giving AI extra grip or fake physics or whatever. One thing I learned is that I am nearly incapable of working on things that I'm not interested in, especially when the work is so intellectually demanding as coding. The AI in LFS use the same physics as the player.

2) This is not a good time for me to waste more time, trying to make AI faster in the old (current public) physics system. If you had followed the thread, you would know that I am trying to release this update as an official version, so I can finally work on the version of LFS we are all waiting for, which has new tyre physics and AI that is already adapted to that new physics. So as I keep saying, I'm not working on the speed of AI in the current public version, fake physics for AI (never will do that in my life) or any other physics changes. There were some slight physics changes done to make the bike handle better, but I'm sure I made it clear that's as far as I was going.

So... to summarize any relevant point, it is possible that official cars or some mods actually run slower, but as mentioned, the mods in general can actually stay on track instead of spinning off at any tricky corner.
Scawen
Developer
I understand why you chose to use unrealistic settings before, even if I don't agree with that approach.

To make a good mod in the proper way, the thing is to get as accurate values and settings as possible. If there are physical problems it's really my job to sort that out by improving the physics model. I do understand slight tweaks to mods to deal with imperfect physics.

But the mod still has massive downforce now, even after the steering model changes. Speaking as a mod user (not as a developer) I'd like to explain that makes me simply not want to use the mod at all. No bike in the world has F1-style downforce, as it's impossible. In my opinion the undertray should be deleted, the downforce set to zero and then work on the bike's geometry, mass, weight distribution, suspension, drag, etc. to make it as near to a real 600 as possible, then it will be a fun mod to use.
Scawen
Developer
Quote from JayDeM :May I ask what you mean when you reference incompatible version?

I've already done most of the work for an incompatible version, with improved mod support. It's a relatively minor update, an intermediate version still using the old physics and graphics, but has better support for mods.

It's intended to become version 0.7E after a short period of testing. I hope the short period of testing can begin in about two weeks from now if I can finish a few things.

Some of the updates in it were listed here: https://www.lfs.net/forum/thread/104758
Scawen
Developer
Quote from evandroPRO123 :Is it possible to add an on/off switch to the "miscellaneous" tab for the motorcycle's steering system? I believe that if there is a way to walk with the stabilizers turned off, it is possible to maneuver, so that the stabilizer does not interfere, thinking that we would fall

No, I think you believe that there is a separate system that is acting as a stabiliser. In fact the entire balancing mechanism and steering are lumped together into a steering model. The user sets the lean, then the steering model attempts to achieve that lean solely by adjusting the front wheel steering. It's a very challenging coding task, as you can see by the two weeks it took me to get to D45, after D44.

The solution I would really like, as mentioned before, would be to have a "physics" model (simulating gyroscopic effects) and a separate "steering" model that is applied on top of that, but that is not the case at the moment and will not be the case, certainly in the 'old' LFS physics.

As I say, quite often, I am trying to get off this test patch so I can get back to the new physics so I can release the new graphics system that everyone wants. If I don't finish it, then it can't be released.

I don't think everyone understands quite how extremely active this bike balancing needs to be, to keep the bike upright at all. Without the steering model constantly adjusting the front wheel, the bike will fall instantly. For example, if the user had direct control of the handlebars, it would be impossible to keep the bike up. The balancing code is actually adjusting the steering 2000 times per second to keep the bike upright.

At this point I will only fix serious problems. I'm not going to be working on the bikes going off road in the old tyre model, or implementing a full bike physical dynamics system at this time.


EDIT: The only system like "stabiliser" that balances the bike using external forces is the "walking" or "feet down" model that takes place up to 2 m/s (7 km/h). Above 7 km/h all balance comes from the front wheel, attempting to achieve the lean angle requested by the user input.
Last edited by Scawen, .
Scawen
Developer
Bike riders, please can you test the new bike steering model in D45? It's a lot more stable when changing gear and braking, also it should be better at low speeds thanks to a separate low speed model.

I'll read the other posts since D44 again and make notes to see what I can do or reply as needed. My main focus has been trying to improve this bike model which became less stable due to an improvement in D44. In this version, the underlying physics is unchanged, only the code that steers the front wheel is different. After the bikes are done, I can get back to finish the intermediate incompatible version with improved mod support, so finally I can get back to the development version and new tyre model.

This diversion onto bikes has taken a lot longer than expected, but I know there are a lot of people who enjoy the bikes and I wanted to make it more acceptable for now.


Changes in D45:

New more stable steering model for bikes:

Improved handling and braking ability
A new high speed model is used for speeds above 72 km/h
A special low speed model is used for speeds below 36 km/h
Models are interpolated between 36 and 72 km/h

AI:

Bike can now brake harder (safety margin the same as cars)
FIX: A hang generating path for a mod with "Max up" wrongly set
FIX: Downshift avoidance was too strong (sometimes needed clutch)

Interface:

A message shows the name of any mod that can't be loaded in an SPR


Download:

https://www.lfs.net/forum/thread/102117
Scawen
Developer
Thank you all for the feedback.

About bikes, I can clearly see the issues you report, not only wobbling when braking from high speed, but a lot of movement when coming off or applying the throttle, or tapping the brake a little when leaned over.

I've experimented quite a bit but haven't got any conclusive improvements yet. It seems like I can dial out any issue but doing so always causes other issues at other speeds or conditions. For example I've been able to get really nice accelerating and braking while leaned over at medium to quite high speeds, but then it's a lot worse when the bike hits a relatively small bump and seriously overreacts. The trouble is that what I call the "damping" part of steering (that tries to reduce wobbling by bringing the lean rate near zero) needs to be quite high to react quickly to certain things, but it needs to be gentle in other situations.

I also tried the early stages of a more physical model which tries to simulate gyroscopic forces and really apply steering forces to that. To separate a bike's natural handling, from forces applied by the arms. But it seems a little distant for me to produce such a genuine physical model at this time and I'd rather not do that with the old tyre physics. And a complete model would need body movement too, which isn't for now.

So in that case I'm left with the original plan to improve our semi-physical model (the bike is in physics but the steering is just doing what it needs to do to balance that bike at the required lean). I still hope to improve it, given my increased understanding learned last week, now that we have better bikes and more of a range to test it on, it seems like I should be able to improve it in some way.
Scawen
Developer
Quote from JayDeM :Hey scawen! can you give us a bit more info on what was changed for the motorcycles? I know you said it affects lean angle and tyre forces but was wondering if we could get a tad more detailed Smile

Yes, actually there were two things.

1) Insufficient lateral acceleration for given lean angle.

When testing for another bug (with a lot of bikes on track) I noticed that the mod "VELOCIPISTO" kept running wide. After a lot of investigation I discovered that any bike with relatively heavy wheels and a light bike would run wide. At first I thought it was a bug in the AI code, but much experimentation didn't solve the problem. I took the observed issue to an extreme with an extremely light bike and thin wheels with no rider. What was actually happening in that case was the bike could lean A LOT but the lateral acceleration did not match up. For example, by the laws of physics, if a bike has thin wheels, and rides in a circle at constant speed, then with 45 degree lean, the lateral acceleration should be 1G. However, this was not the case. For heavier bikes, the wheels are relatively light compared with bike+rider, so the anomaly is not that noticeable.

The actual physics flaw: It turned out that the weight of the wheels was applied at the contact patch, rather than the centre of the wheels. Through all the years, this had never been noticed. Actually, this is because the effect is so tiny for cars, as the wheels are vertical, it makes barely any difference if the weight is applied at the centre of the wheel or the contact patch. For this reason, I've left it the same for the cars, mainly to preserve the hotlaps. It is fixed in the development version for all vehicles, but in the public version it is in a special version of the physics update used only by karts and bikes.

2) Front wheels taking a wider line

I had kept noticing that the front of bikes took a significantly wider line than the rear wheels. It doesn't match up with my observations of real bikes. During my initial investigation of the lean problems noted above, I tried something which was to simply remove the effect of "camber thrust" and rely purely on slip angle to provide the lateral force. I was able to make this only affect the bike wheels, so that, again, the car physics are unaffected. In reality, camber thrust is a real phenomenon, so just removing it isn't really the answer. But the actual answer is to release the new physics that I have in development, and make sure that camber thrust is correctly simulated there. Apparently, in the current public LFS, it is excessive, or at least was excessive at large lean angles, leading to the strange slightly sideways motion of bikes around corners. Anyway, it looks a lot better now and I believe the bikes have a more stable lean angle when throttle or brake are applied mid-corner.
Scawen
Developer
Test Patch D44 has some more improvements including better (safer) braking and faster bikes. I've tried to deal with some of the issues that come up when bikes are allowed to go faster.

Mainly:
- improve line following by fixing a physics flaw
- taking off over bumps at high speed
- braking too hard for their ability
- unnecessary downshifts

The bikes are a fair bit faster now but there are some issues, with some bikes on some tracks. If you have problems you can turn them down to (approximately) their D43 speed by selecting OK instead of PRO.

Examples:
- Mod 'Cruiser' keeps crashing at AS4 due to wobbles at speed
- Fast bikes crash due to bumps before the South City underpass

I can't yet make LFS detect which bikes will be a problem so should go slower, or detect where fine bumps will bounce them into the air, but it's more fun to let the AI go faster so at this point I think it's better to leave it up to you to slow the bikes manually when needed.

The car AI drivers are better at staying on their line at the corners because of two changes: (1) taking account of engine braking and (2) allowing an extra safety margin when braking. In some cases they may be slightly slower but it's a reasonable price to pay for much more reliable AI across the board.

Other known issues:
- AI can sometimes stall but don't know how to restart engine.
- Some karts at some tracks can repeatedly regenerate path (waiting to reproduce).
- AI were reported as being rougher in D43. Maybe they are better now they have a braking safety margin?
- EV regen does not correctly match brake force. E.g. front and rear force arrows not equal at 50% balance.

Changes in D44:

Misc:

Improved bike physics (affects lean angle and tyre forces)
FIX: Engine brake reduction had no effect for EV but was visible
FIX: Replay OOS after a reset attempt was prevented and long wait

AI:

Bike cornering and acceleration limits increased by 25%
Bikes slow to avoid taking off over large humps in the road
AI braking prediction now takes account of engine braking
Braking prediction includes a safety margin to avoid late braking
Avoid unnecessary downshifts by looking ahead to see if needed
Reset is available even after engine switched off after long wait
FIX: Sometimes could reach a maximum speed and stop accelerating

Download:

https://www.lfs.net/forum/thread/102117
Scawen
Developer
Thank you all very much for the feedback and reports since Friday's test patch (D41).

Tankslacno, that must be the best presented patch report I have ever received! Smile

I am fixing the things which are definite bugs, especially if they were introduced recently. Some things won't be fixed but I will look at all the reported issues and see what I can do in a short time.


NOTE: I seriously want to move away from AI, as soon as possible, to get back to finish and release the recent updates to the mods editor and system (the intermediate, incompatible patch with the existing physics and graphics). So I'm just trying to round off the most important issues.
Scawen
Developer
That is exactly what I will not be doing for the AI in the old physics system. Anything related to grip, tyres, etc, would be a waste of time because it would not apply to the new tyre physics. As mentioned, I've already made the AI better at using the available grip in the development version (although there is far more that could be done).

For this update that I've been working on for a few days, it's the overtaking that I am improving. The recent, unscheduled, look at AI (started by watching the bike AI) alerted me to the problems with overtaking and ramming.

Work on this applies equally to the public version and the development version, so it's not a waste of time.
Scawen
Developer
I've done some updates for overtaking that more sensibly group the cars in front together, instead of taking each one as a separate object to pass. It's hard to describe in words, but it boils down to a single "left" or "right" or "brake" decision on the group, instead of doing that separately for individuals then choosing one of the results. It means that more sensible decisions can be taken. Also it can add more AIs that aren't directly in front but are beside the cars that are in front, so hopefully they can make their way around a pileup. It's not a navigation algorithm but makes a better estimate of how far right or left it may have to go.

Just for the record, the bikes aren't slow because I have somehow failed to notice that they are slow. It's because if I turn them up any more it is very unlikely they will make a lap. They'll run wide or ground out or wobble at a bump and generally wipe out far too often. The bike AI are super sensitive to bumps and jumps in the road and as I mentioned before, there are issues with the tyre physics. So bike AI speed is not something to spend a lot of time on at the moment.

Years ago I updated the development version quite a bit, to make the cars a bit more competitive. Unlike in some games, the AI in LFS use the same physics as human drivers, and it's not an easy task to make them simply drive faster. The level of understanding for where you can push and the lines to take, is not an easy thing to code.
Scawen
Developer
Thanks for the feedback. I've released D40 which should solve some issues and hopefully doesn't introduce serious problems!

Quote from UnknownMaster21 :AI seems to wobble it's bike on certain tracks.
...
Most likely on AS4 and KY3 ( when entering track from pitlane )

I think wobbling is worse on some bikes than others. I tested with 6 bikes on the tracks you said, and the only one that really wobbled was the Mosquito (with passenger). I found it hard to improve wobbling when I looked into it the other day. I think that will have to wait for the new tyre physics. But if there is a situation where many bikes wobble, I'll have a look.

Quote from Bokujishin :...I found 3 issues with them:
  • At the start of the race, most AI have a very poor launch, as they brake for no apparent reason and also swerve quite a lot (see XRR replay).
  • Some cars can end up in a massive pileup and stay there for a while for no apparent reason (see XRR replay).
  • They tend to "move under braking", or at least AI FBM do, especially if you're on the outside and force them away from their line, they tend to move to the outside and push you (see FBM replay, where I try to force AI out of their standard line, especially at T1 on lap 3).

The first item, is probably that reported by bobloblaw above, which should now be fixed.
The second item, I noticed this, it was a newly introduced bug, now fixed.
The third item, I'm not sure about. It sounds like something that could have always been the case. Or do you think it's something new?


Changes in D40:

- Safer bike overtaking distances (hopefully not too far)
- Consideration of barriers more dependent on current offset from ideal line
- Distance to vehicle ahead considered dangerous, now depends on length of vehicles
- Much more likely to attempt overtake, when previously stuck behind a slower vehicle
- FIX: Could brake if slightly faster than another car but the other car is accelerating
- FIX: Sometimes applied brakes and stopped on track next to another vehicle

Download: https://www.lfs.net/file_lfs.php?name=LFS_PATCH_7D_TO_7D40.exe
Scawen
Developer
I hope the improvements are all good. Yesterday's overtaking improvement should apply to all AI.

I assume that mixing different vehicle types, and AI driving large vehicles, are no worse in D39 than they were in any other versions. If anyone can show that anything has got worse, I'd like to know about it.

I suppose the code for AI to avoid collisions is built on assumptions that the other vehicles will follow similar lines and be at similar speeds, as they would in real racing. The old LFS tyre physics is stretched to the limit (or should I say beyond the limit) with bikes and heavy vehicles. At this point I don't think it's a good idea for me to spend any time trying to make AI drivers work any better with the old tyre physics. Instead I should get back to finishing the intermediate incompatible update with improvements for mods.

As mentioned, I would like to hear if any AI behaviour has got worse, or any more specific and repeatable issues with the new bike AI.
Scawen
Developer
I've done some AI updates and copied them into the D37 test patch.

AI can now drive objects (do nothing) or motorbikes (slowly)

EDIT: AI can also enter in configs with no path, but will just sit there.

This started from a request to allow the AI to use objects, so they can be tested offline. It's an old thing on my list. But it seemed best to allow all mods, not just objects. That means motorbikes had to be supported. Well, a "few hours" turned into quite a few days. So, sorry about the delay to other things. I have stopped short of trying to really get the best out of them. There are issues with the tyre physics and the bikes actually work better in the new tyre physics.

If you are interested in object mods or bikes, please have a go with the new AI code. It was hard to get them to go round at all on bikes, then there was quite a struggle to get them to leave or enter pits. Hopefully I haven't broken anything for the other AI!

EDIT: Some bikes are too wobbly and crash too often, but maybe you can let me know if enough bikes seem to ride OK at enough tracks.

I know some people will be upset at another delay, but this is an important part of finishing the mods system. Other people will have fun using these AI updates. I've still got the incompatible updates including wheel rim improvements to release in the next few days.

https://www.lfs.net/forum/thread/102117
Last edited by Scawen, .
Scawen
Developer
Hi Morfeas,

A solution is now available. Sorry you had to wait so long.

I was working on something else related to gear shifts so I decided to focus on this specific issue today. I have now made it so that a "fake key press" initiated by a mouse wheel move now lasts for 100ms.

Previously it was as if the key was only pressed for one physics frame, which was not long enough to do the gearshift. Although the ignition cut happened (as you said) the drive train did not become unloaded during that single physics frame, to allow the shift to take place.

The solution seems very reliable to me. I hope you can test it when convenient.

https://www.lfs.net/forum/thread/102117
FGED GREDG RDFGDR GSFDG